[LLVMdev] AVR back end

780 views
Skip to first unread message

Weddington, Eric

unread,
Jun 10, 2013, 3:02:23 PM6/10/13
to llv...@cs.uiuc.edu
Hi All,

For quite some time there's been a side project for developing an AVR back end for LLVM:
http://sourceforge.net/projects/avr-llvm/

What is required from us to be able to add this work to the LLVM repo?

And when do you think would be a good time for us to do that?

If this is located somewhere in the docs and I've missed it, pointers would certainly be appreciated.

Thanks,
Eric Weddington
Marketing Manager
Open Source & Community
Atmel


_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Eli Friedman

unread,
Jun 10, 2013, 3:45:23 PM6/10/13
to Weddington, Eric, llv...@cs.uiuc.edu
On Mon, Jun 10, 2013 at 12:02 PM, Weddington, Eric <Eric.We...@atmel.com> wrote:
Hi All,

For quite some time there's been a side project for developing an AVR back end for LLVM:
http://sourceforge.net/projects/avr-llvm/

What is required from us to be able to add this work to the LLVM repo?

http://llvm.org/docs/DeveloperPolicy.html is the general developer docs (see in particular "Making a major change" and "incremental development"); the only thing that's really specific to backends is that each backend has to have an active LLVM developer who owns it.

And when do you think would be a good time for us to do that?

As soon as possible.  (Even if it isn't ready, sending in patches which can get reviewed as soon as possible is important; the review process can take a while for a major change.)

-Eli

Anitha B Gollamudi

unread,
Jun 12, 2013, 3:18:27 AM6/12/13
to Weddington, Eric, llv...@cs.uiuc.edu
On 11 June 2013 00:32, Weddington, Eric <Eric.We...@atmel.com> wrote:
>
> Hi All,
>
> For quite some time there's been a side project for developing an AVR back
> end for LLVM:
> http://sourceforge.net/projects/avr-llvm/
>

Eric,

Interesting. I tried few non-trivial programs on linux. They got compiled :-)

I would say this is the right time to get the target to ToT. Ofcourse
compiling at -O0 looks like a problem.

While I understand that it is still a pre-alpha version as noted on
website, can you roughly outline the level of backend (llc) support?
(for e.g, basic/OK/pretty much all ISA support, target specific
optimizations - none/few/many)


-Anitha

Carlo Alberto Ferraris

unread,
Jun 12, 2013, 6:59:39 AM6/12/13
to llv...@cs.uiuc.edu
Is PROGMEM supported? Also, AFAIK, GCC is apparently unable to leave
some auxilary data (such as vtables) in PROGMEM and therefore all
vtables are loaded in RAM. Is your backend able to leave such data in
PROGMEM?

Borja Ferrer

unread,
Jun 12, 2013, 2:05:38 PM6/12/13
to llv...@cs.uiuc.edu
@Anitha
The backend is on the stage of being able to compile any program independently of its complexity, atleast that is the theory, any failures should get fixed. The only missing C language feature/extension I know of now is inline asm, which is currently being worked on. It has support for varargs and variable sized allocas.

The backend has support for 95% of the ISA, including all adressing modes (predec, postinc and indexed) for both data and program address spaces. Currently, the only code emission mode supported is text, in the future object file emission should be implemented, for now we require an external assembler and linker. No support now for subtargets.

Regarding optimizations, it has very few implemented. I've focused first on getting correct code generation for any program, and then when the backend is sort of stable get focused on getting those optimizations done.

On the frontend side, we're using clang. We have support for ISR's (signal and interrupt function attributes) and for the __flash keyword to store data in program memory using the named address space extension.

@Carlo
I haven't tested any C++ program with the backend so no idea about that. We don't have those sort of optimizations implemented yet so it will depend on the default llvm behaviour. It's something that will get done in the future, aswell as storing jump/switch tables in progmem.

If you want to know any other specific thing about the backend let me know.
Reply all
Reply to author
Forward
0 new messages